IBIS Macromodel Task Group Meeting date: 17 December 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that this would be the final meeting of 2019 and thanked everyone for their work this year. ------------- Review of ARs: - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - In progress. Arpad asked if we should consider tabling this one until we have an update. Walter agreed. Walter noted that he'll be serving on an AMI panel at DesignCon, and one subject is DDR5. Walter noted that he will talk about the DDR5 DQ Write protocol we are developing, and he will invite other memory and controller vendors to participate. Michael M. said he was okay with tabling it. Walter moved to table it. Michael M. seconded. There were no objections. Arpad said he would move it to the Tabled AR list. - Walter and Randy to work on a new iteration of a proposal for BIRD198. - In progress. Randy noted that he and Walter had discussed this privately, but Walter said they did not yet have anything ready for review with ATM. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Review of the minutes for the December 03 meeting had been deferred at the December 10 meeting: Arpad asked for any comments or corrections to the minutes of the December 03 meeting. Walter moved to approve the minutes. Curtis seconded the motion. There were no objections. Arpad asked for any comments or corrections to the minutes of the December 10 meeting. Walter moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: Arpad suggested a quick review of the existing Tabled ARs: - Investigate if/why/how a clock waveform input might be used. - Randy noted that his AR was still in progress, they are looking into how this would be added to their models, and they will likely reach out to EDA tool vendors. Randy stated that this will probably require input from everyone to look at simulation flows in the tools. - Michael M. said his answer was similar. This issue can be handled in many ways, but one question is on whom does the burden fall? Do we rearchitect models to deal with it, or are there ways to finesse this at the risk of slightly reduced accuracy? - Arpad noted that these two will stay on the Tabled AR list. - Check with IP experts on whether DC_Offset is useful for Tx. - Michael M. said that this could be closed. He noted that they had provided all the feedback they could for now. Arpad said he would remove it from the list. BCI for statistical mode: Walter noted that he had not received any comments via email on his draft 1. He said he thought it was sufficiently formed to submit it to the Open Forum and get an initial BIRD number prior to DesignCon. He asked if people wanted more time to review it. Radek noted that he had mixed feelings about introducing AMI_Impulse(), and he wondered whether we should instead just augment AMI_Init() to address this issue. Walter noted that we had held a straw poll vote at the December 3rd meeting to choose a direction, and AMI_Impulse() had won 6 to 0. Walter noted that the current state of the proposal was what had been decided upon by the vote. Radek said he was not against AMI_Impulse(), he just wasn't sure we gained anything by introducing it. Arpad noted that with the AMI_Init() approach a file was needed to facilitate communication (as in BIRD147), but the new AMI_Impulse() had BCI_parameters_in and BCI_parameters_out arguments for that purpose. Arpad noted that adding a new function might be cleaner than overloading existing functions with additional options and conditions. Radek noted that with AMI_Init() you had the same flags available as for the bit- by-bit BCI simulations, and the only thing we'd talked about overloading was the value passed in by ami_memory_handle. Radek reiterated that AMI_Impulse() could work just fine, he just wasn't sure it was necessary to add the new function. Walter asked people to review the draft and noted that at the first meeting of 2020 he expected to move to submit the current draft, or a draft 2 if we modified anything today, to the Open Forum. Ambrish noted an internal discussion with his colleagues about this proposal. He said that he understood the goal of filling the statistical flow hole, but he said they were interested in knowing if IP industry vendors were actively trying to get this functionality added. He said they would like to chat with any such IP vendors about what they feel they can't do with the bit-by-bit BCI we already have in IBIS. Michael M. said he could answer that question. He noted that almost all of their internal analyses were based on AMI_Init(), i.e., statistical flow. He said that for many reasons their focus is on getting statistical flow results that can be applied to a Design of Experiments. If you want to run very many statistical flow simulations, and your buffer designs are "LTI enough," then the only gap in the current AMI flow for something like PCI Express or other industry standards that use backchannel adaptive equalization is this BCI-in-statistical feature. He noted that right now they have to do that negotiation between the endpoints "manually" in a statistical flow, and they would like to have link training in a statistical flow. He also spoke to Radek's earlier point about AMI_Impulse() vs. AMI_Init(). He said the question is whether you modify AMI_Init() and change your flow, or you add a new function and leave AMI_Init() alone. He said the new AMI_Impulse() function to handle link training would address all of these issues. Ambrish asked if an "LTI enough" buffer design meant we would be talking about a one-vendor solution. He noted we can't make a general assumption that a Tx and Rx are "LTI enough." Michael M. said it was not a vendor-specific issue, it was a methodology. He noted that they had used the same methodology for specification-based generic buffers too. He noted that the model maker might need to make additional assumptions about how a buffer design really works, but for something like PCI Express there's enough information in the standard to formulate a statistical model set to do this type of statistical mode analysis. Arpad brought up the long-standing questions and discussions about Init Only vs. GetWave Only vs. Dual models. He asked what would happen if one model had AMI_Impulse() and the other only had AMI_GetWave() based BCI? Michael M. said he hadn't thought through those details, but the effectiveness of this technique might boil down to whether a device vendor could give you a buffer that was LTI- enough that you could get good results from a statistical analysis. Ambrish noted that back-channel, by its nature, is a long time-dependent simulation that determines the tap weights at either end. He asked how much correlation had been done to see if these statistical results could be accurate enough. Do we have other IP vendors who need this? He said that if a single vendor needs a solution for this problem, it can be handled today by a proxy- model approach like Wei-hsing had described (in previous meetings). Michael M. said he thought the proxy-model approach was non-trivial in a software sense for most model makers. Leaving that issue aside, he noted that PCI_Express, for example, if it's going through one of these training algorithms, is not going to get anywhere near the full 3 x 1/BER target during training. The training takes place over an extremely short period of time, so there's a whole bunch of assumptions made even in the actual system when it's training. So, there are already lots of assumptions even in the full time-domain training flow. Michael said he did not think they were unique in the industry in wanting this statistical BCI flow. Wei-hsing noted that there was already a certain complexity in implementing eye metrics and other issues with training. He said not to underestimate the complexity of implementing the model even with the current AMI_Impulse() proposal. Michael M. said he agreed completely, and that Wei-hsing's comments opened the door to a wider discussion he expects at the DesignCon Summit. He noted that as the AMI flow is currently written, models are returning some simple information like the waveform and modified parameter values, and the EDA tools handle sampling, eye diagrams, eye metrics, etc. He suggested that it might be better if the models reported these things directly, as they could more accurately reflect what the device is actually doing. Walter noted that the metrics returned by the models would be defined by the particular BCI protocol. He noted that we are currently working on our first protocol for DDR5 DQ Write. He said he planned to propose a straightforward method of generating some metrics from the IR output of the Rx, which the Rx model has available. He said he could provide a short MATLAB function as an example. He noted that complexity shouldn't be too bad for this first protocol. Wei-hsing suggested it would be good to implement something that is consistent with other metrics like COM. Walter agreed and noted that the MATLAB function he created computes eye height, eye area, and COM for a given IR and BER. Arpad asked if this proposal was ready to submit to the Open Forum. Michael noted a cut-and-paste type error with "IEEE Std 802.3" appearing before SOLUTION REQUIREMENTS. Walter removed it. Radek noted that the second sentence in the Usage Rules needed editorial work. Walter reviewed it and removed it entirely. Walter asked if anyone wanted to be listed as an author. Arpad asked if Michael should be. Michael suggested he be listed as a "contributor" in the Background Information section. Walter saved the resulting document as draft 2. Walter noted that if you're going to run the statistical BCI flow, then all of the models have to have BCI_Training_Mode "Impulse" or "Dual". If you're going to run the time-domain BCI flow, then all of the models have to have BCI_Training_Mode "GetWave" or "Dual". Arpad noted that all of the models would have to handle the right training mode and understand the same protocol. He asked who would enforce this. Walter said the EDA tool enforces it. The protocol name is contained in a Reserved parameter (BCI_Protocol), so the EDA tool can check to ensure the right protocol and mode are supported by all models. - Michael M.: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. Happy New Year. AR: Walter to email draft 2 of the BCI for statistical proposal to ATM. ------------- Next meeting: 07 January 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives